Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-pppext-isdn-03.txt

Text File | 1993-10-14 | 16KB | 552 lines

Network Working Group                                        W A Simpson
Internet Draft                                                Daydreamer
expires in six months                                       October 1993


                             PPP over ISDN
                     draft-ietf-pppext-isdn-03.txt



Status of this Memo

   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the [e-mail] mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


















Simpson                  expires in six months                  [Page i]
DRAFT                        PPP over ISDN                  October 1993


Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   This document describes the use of PPP over Integrated Services
   Digital Network (ISDN) switched circuits.


Applicability

   This specification is intended for those implementations which desire
   to use the PPP encapsulation over ISDN point-to-point links.  PPP is
   not designed for multi-point or multi-access environments.

   "It is clear that there is never likely to be a single, monolithic,
   worldwide ISDN." [7] The goal of this document is to describe a few
   common implementations, chosen from the current wide variety of
   alternatives, in an effort to promote interoperability.
































Simpson                  expires in six months                 [Page ii]
DRAFT                        PPP over ISDN                  October 1993


1.  Introduction

   PPP was designed as a standard method of communicating over point-
   to-point links.  Initial deployment has been over short local lines,
   leased lines, and plain-old-telephone-service (POTS) using modems.
   As new packet services and higher speed lines are introduced, PPP is
   easily deployed in these environments as well.

   This specification is primarily concerned with the use of the PPP
   encapsulation over ISDN links.  Since the ISDN B-channel is by
   definition a point-to-point circuit, PPP is well suited to use over
   these links.

   The ISDN Primary Rate Interface (PRI) may support many concurrent B-
   channel links.  The PPP LCP and NCP mechanisms are particularly
   useful in this situation in reducing or eliminating hand
   configuration, and facilitating ease of communication between diverse
   implementations.

   The ISDN D-channel can also be used for sending PPP packets when
   suitably framed, but is limited in bandwidth and often restricts
   communication links to a local switch.

   The terminology of ISDN can be confusing.  Here is a simple graphical
   representation of the points used in subsequent descriptions:

                   +-------+     +-------+     +-------+
               R   |       |  S  |       |  T  |       |   U
               +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
                   |       |     |       |     |       |
                   +-------+     +-------+     +-------+

   These elements are frequently combined into a single device.


















Simpson                  expires in six months                  [Page 1]
DRAFT                        PPP over ISDN                  October 1993


2.  Physical Layer Requirements

   PPP treats ISDN channels as bit or octet oriented synchronous links.
   These links MUST be full-duplex, but MAY be either dedicated or
   circuit-switched.

   Interface Format

      PPP presents an octet interface to the physical layer.  There is
      no provision for sub-octets to be supplied or accepted.

      The octet stream is applied primarily at the R or T reference
      points.

   Transmission Rate

      PPP does not impose any restrictions regarding transmission rate,
      other than that of the particular ISDN channel interface.

   Control Signals

      PPP does not require the use of control signals.  When available,
      using such signals can allow greater functionality and
      performance.  Implications are discussed in [2].

      Control signals MAY be required by some of the framing techniques
      described, and is outside the scope of this specification.

   Encoding

      The definition of various encodings and scrambling is the
      responsibility of the DTE/DCE equipment in use, and is outside the
      scope of this specification.

      While PPP will operate without regard to the underlying
      representation of the bit stream, lack of standards for
      transmission will hinder interoperability as surely as lack of
      data link standards.  The D-channel LAPD interface requires NRZ
      encoding at the T reference point.  Therefore, as a default, it is
      recommended that NRZ be used over the B-channel interface at the T
      reference point.  This will allow frames to be easily exchanged
      between the B and D channels.

      When configuration of the encoding is allowed, NRZI is recommended
      as an alternative in order to ensure a minimum ones density where
      required over the clear B-channel, with caveats regarding FCS [2].

      Historically, some implementations have used Inverted NRZ (merely



Simpson                  expires in six months                  [Page 2]
DRAFT                        PPP over ISDN                  October 1993


      switching the sense of mark and space), in order to ensure a
      minimum ones density with bit-synchronous HDLC.  The use of
      Inverted NRZ is deprecated.

      Automatic Detection

         Implementations which desire to interoperate with multiple
         encodings MAY choose to detect those encodings automatically.
         Automatic encoding detection is particularly important for
         Primary Rate Interfaces, to avoid extensive pre-configuration.
         Only simple encodings are currently distinguished.

         The only reliable method of detection available is to switch
         modes between the supported encodings.  Transmission of the LCP
         Configure-Request SHOULD be tried twice for each mode before
         switching in rotation.  This ensures that sufficient time is
         available for a response to arrive from the peer.

         Max-Configure MUST be set such that the cumulative attempts
         result in no more than 59 seconds of time before disconnect.
         It is preferable that the usual limit of 30 seconds be
         observed.

      Prior Configuration

         By prior configuration, PPP MAY also be used with other
         encodings.  Because of difficulty distinguishing them, it is
         not recommended that these encodings be automatically detected.

         Terminal adapters conforming to V.120 [6] can be used as a
         simple interface to workstations.  Asynchronous HDLC framing
         [2] is accepted at the R reference point.  The terminal adapter
         provides async-sync conversion.  Multiple B-channels can be
         used in parallel.  Unfortunately, V.120 has a framing mode of
         its own for rate adaptation, which is difficult to distinguish
         from Frame Relay, and which can confuse in-band frame
         detection.  V.120 is not interoperable with bit-synchronous
         links, since V.120 does not provide octet-stuffing to bit-
         stuffing conversion.  Therefore, V.120 is deprecated in favor
         of more modern standards, such as "PPP in Frame Relay" [4].

         The "Bandwidth On Demand Interoperability Group" has defined a
         proposal called BONDING.  Multiple B-channels can be used in
         parallel.  BONDING has an initialization period of its own,
         which might conflict with the simple detection technique
         described above, and requires extensive individual
         configuration in some current implementations when multiple B-
         channels are involved.  It is recommended that the PPP



Simpson                  expires in six months                  [Page 3]
DRAFT                        PPP over ISDN                  October 1993


         multilink procedure [5] be used instead of BONDING.


3.  Framing

   For B-channels, in the absence of prior configuration, the
   implementation MUST first use bit-synchronous HDLC [2], as opposed to
   other framings, for initial link establishment.  This assumes that
   circuit-switched communications are generally [host | router] to
   [host | router].

   By prior configuration, octet-synchronous HDLC [2] is recommended
   where the network termination equipment interfaces directly to the T
   reference point, and octet boundaries are available at the time of
   framing.  Such equipment is likely to be highly integrated, and the
   elimination of bit-synchronous hardware can reduce the part count,
   resulting in lower cost interfaces and simpler configuration.
   Octet-synchronous HDLC MUST be used with NRZ bit encoding.

   For D-channels, by default no data service is expected.  By prior
   configuration, "PPP in X.25" [3] or "PPP in Frame Relay" [4] framing
   MAY be used.

   Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
   distinguishable, multiple methods of framing SHOULD NOT be used
   concurrently on the same ISDN channel.  There is no requirement that
   PPP recognize alternative framing techniques, or switch between
   framing techniques without specific configuration.























Simpson                  expires in six months                  [Page 4]
DRAFT                        PPP over ISDN                  October 1993


4.  Out-of-Band signaling

   Experience has shown that the LLC Information Element is not reliably
   transmitted end to end.  The deployment of compatible switches is too
   limited, and the subscription policies of the providers are too
   diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
   upon for framing or encoding determination.

   No LLC-IE values which pertain to PPP have been assigned.  Any other
   values which are received are not valid for PPP links, and can be
   ignored for PPP service.

   As an alternative administrative measure, multiple directory numbers
   can point to the same physical access facility, by binding particular
   services to each directory number.  The called party identifier has
   proven to be reliably provided by the local switch.

   When a called party identifier is used, or when a future LLC-IE value
   is assigned to PPP and the PPP value is received, if the LCP has not
   had the administrative Open event, the call MUST be rejected.
   Receivers MUST NOT accept an incoming call, only to close the circuit
   or ignore packets from the circuit.


5.  Configuration Details

   The LCP recommended sync configuration options apply to ISDN links.

   The standard LCP sync configuration defaults apply to ISDN links.

   The typical network feeding the link is likely to have a MRU of
   either 1500, or 2048 or greater.  To avoid fragmentation, the
   Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
   exceed 1500, unless a peer MRU of 2048 or greater is specifically
   negotiated.

   Instead of a constant value for the Restart timer, the exponential
   backoff method is recommended.  The Restart Timer SHOULD be 250
   milliseconds for the initial value, and 3 seconds for the final
   value.

   Implementations that include persistent dialing features, such as
   "demand dialing" or "redialing", SHOULD use mechanisms to limit their
   persistence.  Examples of such mechanisms include exponential
   backoff, and discarding packet queues after failure to complete link
   establishment.  In some implementations, discarding the transmit
   queue can temporarily remove the stimulus to retry the connection.




Simpson                  expires in six months                  [Page 5]
DRAFT                        PPP over ISDN                  October 1993


Security Considerations

   Security issues are not discussed in this memo.


References

   [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
         progress.

   [2]   Simpson, W.A., "PPP in HDLC Framing", work in progress.

   [3]   Simpson, W.A., "PPP in X.25", work in progress.

   [4]   Simpson, W.A., "PPP in Frame Relay", work in progress.

   [5]   Sklower, K., "PPP MultiLink Procedure", work in progress.

   [6]   CCITT, "Recommendation V.120: Data Communications over the
         Telephone Network", Blue Book, ITU 1988

   [7]   Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
         1992.


Acknowledgments

   This design was inspired by the paper "Parameter Negotiation for the
   Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
   University of California, Berkeley, 1992, unpublished.

   Other details were gleaned from "Determination of Encapsulation of
   Multi-protocol Datagrams in Circuit-switched Environments", Keith
   Sklower, University of California, Berkeley, IETF IPLPDN WG draft,
   July 1993.  That paper credits previous work "A Subnetwork Control
   Protocol for ISDN Circuit-Switching", Leifer, D., Sheldon, S. and
   Gorsline, B.; IETF IPLPDN WG draft, March 1991; and "A Negotiation
   Protocol for Multiple Link-Protocol over ISDN Circuit-Switching",
   Muramaki, K. and Sugawara, T.; IETF IPLPDN WG draft, May 1992.

   Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
   Leifer (University of Michigan) for technical details and called
   party signalling, and Vernon Schryver (Silicon Graphics) regarding
   handling of link misconfiguration and timeouts.

   Special thanks to Morning Star Technologies for providing computing
   resources and network access support for writing this specification.




Simpson                  expires in six months                  [Page 6]
DRAFT                        PPP over ISDN                  October 1993


Chair's Address

   The working group can be contacted via the current chair:

      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California  93117

      EMail: [e-mail]


Author's Address

   Questions about this memo can also be directed to:

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

      EMail: [e-mail]




























Simpson                  expires in six months                  [Page 7]
DRAFT                        PPP over ISDN                  October 1993


                           Table of Contents


     1.     Introduction ..........................................    1

     2.     Physical Layer Requirements ...........................    2

     3.     Framing ...............................................    4

     4.     Out-of-Band signaling .................................    5

     5.     Configuration Details .................................    5

     SECURITY CONSIDERATIONS ......................................    6

     REFERENCES ...................................................    6

     ACKNOWLEDGEMENTS .............................................    6

     CHAIR'S ADDRESS ..............................................    7

     AUTHOR'S ADDRESS .............................................    7































[e-mail]